/**
 * @PROJECT_NAME: design_patterns
 * @DESCRIPTION: 命令模式 Command Pattern
 * 定义：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分隔开，这样两者之间通过命令对象进行沟通，
 * 这样方便将命令对象进行存储、传递、调用、增加与管理。
 * <p>
 * 结构：
 * <p>
 * 抽象命令（Abstract Command）类：定义命令的接口，声明执行的方法。
 * <p>
 * 具体命令（Concrete Command）类：具体的命令，通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
 * <p>
 * 实现者/接收者（Receiver）角色：接收者，真正执行命令的对象，任何类都可能成为一个接收者，只要它能够实现命令要求实现的响应功能。
 * <p>
 * 调用者/请求者（Invoker）角色：要求命令对象执行请求，通常持有命令对象，可以持有很多命令对象，这个是客户端真正触发命令要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
 * <p>
 * 案例：酒店订餐场景，顾客把订单交给服务员-->服务员把订单交给前台-->厨师根据订单准备餐点。
 * <p>
 * 服务员：就是调用者角色，由她来发起命令。
 * <p>
 * 厨师：就是接收者角色，真正命令执行的对象。
 * <p>
 * 订单：命令中包含订单。
 * <p>
 * 优缺点：
 * <p>
 * 优点：
 * 降低系统的耦合度，命令模式能将调用操作的对象与实现该操作的对象解耦。
 * <p>
 * 增加或删除命令非常方便，采用命令模式增加与删除命令不会影响其他类，它满足“开闭原则”，对扩展比较灵活。
 * <p>
 * 可以实现宏命令，命令模式可以与组合模式结合，将多个命令装配成一个组合命令，即宏命令。
 * <p>
 * 方便实现 Undo 和 Redo 操作，命令模式可以与后面介绍的备忘录模式结合，实现命令的撤销与恢复。
 * <p>
 * 缺点：
 * <p>
 * 使用命令模式可能会导致某些系统有过多的具体命令类。
 * <p>
 * 系统结构更加复杂
 * <p>
 * 使用场景
 * <p>
 * 系统需要将请求调用者和请求接收与解耦，使用调用者和接收者不直接交互。
 * <p>
 * 系统需要在不同的时间指定请求，将请求排队和执行请求，
 * <p>
 * 系统需要支持命令的撤掉（Undo）操作和恢复（Redo）操作。
 * @AUTHOR: CNBruceLee
 * @DATE: 2021/8/30 22:49
 */
package com.bruce.demo2.patterns.demo3.behavioral.demo15.command;
